Port to LoongArch64 #257
Port to LoongArch64 #257
Conversation
zunley
commented
Aug 23, 2021
zunley
commented
|
This is the manual for the LoongArch64. |
|
My understanding is that this is a brand new (only announced a few months ago) proprietary CPU, generally being produced for the Chinese domestic market. Have you verified this on actual hardware, or just an emulator? How would I go about verifying this (presumably in…some... emulator with…some...Linux distro? I haven't looked, but I don't think I've even heard of Linux distros supporting this new CPU yet)? |
|
@jamadden The linux kernel is also processing, at the same time we build our OS base on linux for this CPU. So when building the OS, we are also actively seeking support from the upstream community. Finally, I run these on a physical machine, because both the machine and OS are available. If you are interested in this ISA, you can also try it. |
That is my question: How do I try it? Which open source Linux distribution do I install in which open source emulator in order to try it? I need step-by-step instructions, please. My understanding is that neither the kernel nor userspace has been released (upstreamed) yet. That suggests that they are still subject to change, which means this patch can quickly bit rot. |
| #define STACK_MAGIC 0 | ||
|
|
||
| #define REGS_TO_SAVE "s0", "s1", "s2", "s3", "s4", "s5", \ | ||
| "s6", "s7", "s8", "fp", \ |
There was a problem hiding this comment.
Are you sure fp can be included? I see this in my independent port before I saw your PR:
loongarch64-unknown-linux-gnu-gcc -fPIC -I/home/xenon/greenlet-venv/include -I/usr/include/python3.9 -c src/greenlet/greenlet.c -o build/temp.linux-loongarch64-3.9/src/greenlet/greenlet.o
In file included from src/greenlet/slp_platformselect.h:59,
from src/greenlet/greenlet.c:370:
src/greenlet/platform/switch_loongarch64_unix.h: In function ‘slp_switch’:
src/greenlet/platform/switch_loongarch64_unix.h:31:1: error: $r22 cannot be used in ‘asm’ here
31 | }
| ^
error: command '/usr/bin/loongarch64-unknown-linux-gnu-gcc' failed with exit code 1
There was a problem hiding this comment.
Yes, I am sure fp can be included. I think your error message is caused by gcc compilation optimization. This is my compilation flags.
loongarch64-loongson-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -g -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/python3.6m -c src/greenlet/greenlet.c -o build/temp.linux-loongarch64-3.6/src/greenlet/greenlet.o
There was a problem hiding this comment.
Hmm, that's not good for portability, you can't force one particular set of CFLAGS, due to different distros just doing their job differently. I know that fp/s9 actually should be saved, but how do we force it in this case? I'm using the latest upstream submission for my toolchain and kernel, and a self-compiled Gentoo userland; let me know if you need the Gentoo tarball to reproduce the issue.
There was a problem hiding this comment.
Yes, I can reproduce this issue in other way. This is indeed a problem.
Inspired by your question, I found this the setup.py. I think we should add appropriate compilation optimization flags for loongarch64 here.
if ((sys.platform == "openbsd4" and os.uname()[-1] == "i386")
or ("-with-redhat-3." in platform.platform() and platform.machine() == 'i686')
or (sys.platform == "sunos5" and os.uname()[-1] == "sun4v")
or ("SunOS" in platform.platform() and platform.machine() == "sun4v")
or (sys.platform == "linux" and platform.machine() == "ppc")):
os.environ["CFLAGS"] = ("%s %s" % (os.environ.get("CFLAGS", ""), "-Os")).lstrip()
There was a problem hiding this comment.
Optimization flags are not the proper way to solve this, in my opinion, because they tend to depend on intricate compiler internals to work. The "solution" will likely be fragile and break when the stars don't align.
Actually, the way most other projects manually save/restore preserved registers is to write concrete asm fragments, even whole .S files; doing this via clobber list is something I have never seen before, yet in this project every port does that. How about noticing your compiler team about this so they can provide some input? @-mentioning them here should be enough.
There was a problem hiding this comment.
@merore 所以这里正确的处理方式是什么？python setup.py bdist_wheel是一样的报上面的错
There was a problem hiding this comment.
@Duanexiao Please refer to the latest commit.
There was a problem hiding this comment.
@Duanexiao Please refer to the latest commit.
gevent项目我看贵司还没提兼容loongarch64的代码？但是龙芯的pypi里面有这个
There was a problem hiding this comment.
gevent项目我看贵司还没提兼容loongarch64的代码？但是龙芯的pypi里面有这个
code here https://github.com/merore/greenlet/commits/master
There was a problem hiding this comment.
gevent项目我看贵司还没提兼容loongarch64的代码？但是龙芯的pypi里面有这个
code here https://github.com/merore/greenlet/commits/master
我说的是gevent项目
The LoongArch port for greenlet hasn't been merged yet [1], so disable for now. [1]: python-greenlet/greenlet#257 Signed-off-by: WANG Xuerui <[email protected]>
The LoongArch port for greenlet hasn't been merged yet [1], so disable for now. [1]: python-greenlet/greenlet#257 Signed-off-by: WANG Xuerui <[email protected]>
The LoongArch port for greenlet hasn't been merged yet [1], so disable for now. [1]: python-greenlet/greenlet#257 Signed-off-by: WANG Xuerui <[email protected]>
|
@jamadden sorry to bother you again. |
- Upstream version 2.0.2. Amongst other things solves FTBFS with GCC 13. - Support LoongArch architecture (from python-greenlet/greenlet#257)
